0.16 to be declared stable Rseding thinks that we have the least amount of bugs in the game we ever had. Mostly because of the automated reporting system and partly because of my pushing of everyone to fix everything before starting other tasks. The 0.16.35 (to be released soon) will be declared stable on Monday, if no critical problems are discovered. This naturally leads us to:
Hello, it is another Friday already, and one step closer to the double-digit temperatures of spring.
Hello, it has been extremely cold these last weeks. It's one of those weeks when we can't think of anything to write about. So we will try to write some small parts.
Belt compression (kovarex) The decision of how to approach the belt compression in 0.16 was not an easy one, we were basically facing two possibilities: Splitters are the only way to reliably compress a belt. Compression is automatic everywhere (inserters, sideloading, mining drills). Non-automatic belt compression is kind of an nice example of emergent gameplay mechanic that I liked. It was not forced on players, but it allowed to get some extra efficiency if they cared enough. On other hand, the solution to the problem is kind of obvious, and having to use it in all the setups everywhere might add more repetitiveness than fun. So after some discussions, we decided to make compression automatic. But we weren't really sure how to do it. The problem is, that once the items are pseudo-randomly added to the belt, with lot of gaps not big enough for another items to fit, it is not clear how should the additional inserters compress it: The solution was, that whenever there is any gap bigger than the standard distance between items on a belt, item can be inserted there and for a (usually) brief moment, the items are squashed together closer than usual. But once the belt starts moving, the gap between the two squashed item extends to the standard size. This change required us to do some fundamental changes to the belt logic, which could introduce a lot of new problems, but since we just wanted this to be resolved in 0.16, we had to do it now. The result is, that the same setup in 0.16.25+ results in perfectly compressed belt: The belt mechanics are now easier to use, but the game also flows more nicely. The belt flow still needs to be controlled and belt balancers are still needed. As that feels to be the more interesting part of belt handling to me, I am happy with the final result.
Hello, on Thursday we received a belated Christmas package from our friends over at Steam: They definitely won't be lasting long :-).
Taipei Game Show 2018 (Twinsen) After a long 14 hour flight back, Albert, kovarex and I arrived back from Taipei, after our attendance at the Taipei Game Show. Jitka started her vacation by staying there to visit the Taiwan island. We stayed there for 7 days (2 days in the business area, 3 days in the convention area and 2 days of free time where we visited the city). In the business area we met many potential business partners and got way too many business cards. We made some friends among the other indie developers and tried all kinds of fun, weird, interesting and some bad indie games. The convention area was very crowded, with 350,000 visitors slowly trying to make their way through the fairly small convention hall. I can't speak for the others, but I still enjoyed myself. Even though it was crowded, most of the games were in Chinese, and I only got to try one AAA game, there is something about being surrounded by games, gamers, and game developers that makes me feel great. Our booth was in the indie area. We had many people coming to try the game but also many fans wanting to speak with us and congratulate us for making a great game. AndrewIRL who lived there for a few years, invited us for dinner to "the best restaurant in the city", and we were not disappointed. Factorio is not an easy game to demo, since it takes at least 30 minutes to kind of understand what the game is about. But having the trailers looping on the screen, and having subtitles for the gameplay trailer meant that the people got a fair idea about what the game is about and how complex it is. While not the best, we had people start by playing the campaign. Most of them were leaving after the first level but some of them were also getting addicted and playing for multiple hours. We gave free Steam keys to some of the people who were more engaged with the game. It was a learning experience to see people play the game for the first time and to see the most common problems with the campaign, the interaction, the UI and the Traditional Chinese translation. The days were super exhausting though, many of us collapsing at the accommodation and sleeping for 10 hours. Luckily we had 2 more days to relax and enjoy the city before flying back. We mostly split up and each of us visited what they were most interested in, with me going through the electronics markets and riding a rented bike through the rainy streets. To give credit where credit is due, I'd like to thank the game show for inviting us and sponsoring our booths, and Razer for conveniently lending us the laptops we used to demo the game. Financially there is no point in us going to a game show, our attendance did not bring us any extra sales in Asia, as expected. The point of going there, for us, is to visit the show floor, play and see random games, make gamer friends, meet fellow developers, meet big fans of the game and maybe make some business partners. Since many of you mentioned PAX and some of us are interested in going there, we are trying to see if we can attend PAX East this year (April 5-8th). So you might have another opportunity to come and take selfies with some of the Factorio devs. From left to right: Jitka, Albert, Twinsen, kovarex.
Bugfixing report (posila) Stabilization goes well, the game seems to be quite stable right now (as in - not many crashes are being reported), in fact I think we are at the phase where additional bugfixing makes the game less stable, because more bugs are introduced than fixed, or some critical bug slips through our automated tests. But there are still lot of issues that need to be resolved before we declare 0.16 stable and move on to 0.17 development - the largest issue being belt compression problems. We finally fixed compatibility problem with OS X 10.9 Mavericks after it was broken in 0.15.40, when we updated our development environment to a newer version of boost, and was still broken in 0.16.x despite of us completely replacing boost with standard libraries from a newer version of C++. However, we might drop Mavericks support in 0.17, as we are considering migrating the game to OpenGL 4.1, which won’t be available on Macs that are unable to run a newer version of macOS. Speaking of OpenGL, we have several reports of the game crashing in rendering on Linux when the game is disturbed somehow (for example window resizes, loses focus or user switches workspaces), even though it is terribly inconvenient, the game seems to be otherwise playable on these configurations, and we don’t want to spend a terrible amount of time trying to figure out what is wrong with our current rendering system, when we plan to do complete overhaul of it in 0.17. We will investigate these issues, but they might go unresolved until 0.17. I’ve been looking into some corrupted saves this week, still not being able to figure out how these mysterious corruptions occur. For example this save had two iron ore entities on two different chunks saved with zero entity ID. This could have happened only if those entities had a wrong pointer to the iron ore prototype, so when the game read the ID from the prototype on saving, it would read a value from some random part of memory, or if the ID was corrupted on copying from the prototype to buffer that is saved to disk. Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?), but it would be nice to have some proof it is not some dangling pointer in our code that causes random parts of memory to be overwritten by who knows what. One way to test it would be to check for tile corruptions. Tile data for a chunk is allocated in a 4kB array at the beginning of the chunk. We could create custom allocator for chunks, so that data structure representing chunk is aligned to virtual pages. That way tile data would occupy a whole single virtual page which we could flag as read only. Then, if due to a bug we write over tile data, the OS would crash the game and we would get a stacktrace and crash dump to investigate. But if a cosmic ray would hit the RAM and flip a bit, the corrupted save would still be produced. However, we currently don’t do any custom allocation of virtual pages, so it might be quite hard to implement. We also need to change tiles sometimes (when map generation runs, when player uses concrete or landfill, when a script changes tiles, etc.) and we don’t know how expensive it would be to change pages from read only to read-write and then back to read only. So it might be just easier to spend two hours on fixing a broken save that someone sends us once every week or two.
Hello, another week has passed here, with part of the team still out in Taiwan. They should be back next week, with some news of their great adventure.
Hello, this week has been a week of typical bug fixing of 0.16, so development news wise, there is not much to write about. However we have some updates on some other goings on in the company.
